home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / ipae / ipae-minutes-92aug.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  5.2 KB  |  150 lines
  1.  
  2. INTERIM_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Dave Crocker/TBO
  6.  
  7. Minutes of the IP Address Encapsulation Working Group (IPAE)
  8.  
  9. This meeting took place on August 27, 1992 via Videoconference and was,
  10. essentially, a review session for a number of issues.  The one item
  11. which was pursued further was a report from Steve Deering about
  12. Addressing.
  13.  
  14. Administrivia
  15.  
  16. Copies of the current versions of the specifications, Craig Partidge's
  17. BSD diffs, and a few other files are now at PARC.
  18.  
  19. Mike Conn, of MCI, has very gratiously offered to provide a
  20. teleconferencing bridge (telephone) for future meetings.  This will
  21. allow those not able to go to a videoconferencing site to participate
  22. over the phone.
  23.  
  24. Addressing (Steve Deering)
  25.  
  26. Discussion about Geographic-based addressing has gone in the direction
  27. of allowing Provider-based addressing _also]_, to handle the early
  28. stages of the new addressing plan.  It appears that to remain strictly
  29. geographic will require very considerable complexity inside the datagram
  30. routing service, since metropolitan areas are, in no way, guaranteed to
  31. have inter-vendor transfer sites (now dubbed `Metropolitan Internet
  32. Exchange' or ``MIX''.)
  33.  
  34. There is a need to ensure that the primary addressing authority is
  35. independent of any provider.
  36.  
  37. There is also a continuing concern that the MIX concept requires sharing
  38. of customer information between competitors.  They is the retort that
  39. that information is discernible anyhow.
  40.  
  41. Discussions will continue.  Next Addressing meeting will be September
  42. 11th.
  43.  
  44. Side note:  The Group feels that the specifications need to be crystal
  45. clear about the philosophy that is driving their choices, to facilitate
  46. evaluation among the different proposals.
  47.  
  48. ACTION: (Crocker) upgrade specs to emphasize end-user friendly and
  49. installed base friendly intent of IPAE.
  50.  
  51. There is intended to be support for ``multi-homed'' commonwealths.  That
  52. is, a host may have more than one commonwealth ID. This might facilitate
  53. transition issues, such as from vendor-oriented addressing to
  54. geographic, but it still requires the ability to add and delete
  55. addresses.  The question of the way to propagate such information is
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63. still open.
  64.  
  65. IPAE Options
  66.  
  67. At the previous meeting, the question of providing space for IPAE-level
  68. options was discussed and rejected.  At this meeting, we reviewed the
  69. decision, with no one suggesting it be reversed.
  70.  
  71. IPAE Border Router Discovery
  72.  
  73. This was another review topic.  In general, most of the techniques that
  74. are used to discover an IP first-hop router can be re-used to discover
  75. the IPAE first-hop (i.e., border) router.  But John Moy suggested use of
  76. a fixed, logical address, written into the IPAE spec.  This could then
  77. trigger an IPAE-ICMP Redirect, when a logical border router gets the
  78. first IPAE datagram.
  79.  
  80. A concern was raised that this scheme would have trouble if the user
  81. datagram is fragmented, along the way to the border router, and worse,
  82. the fragments traveled to different logical border routers.  The
  83. conclusion was that fragmentation is relatively rare and this is
  84. yet-another strong vote for MTU Discovery.  Further, multiple
  85. destinations occurs only due to path-splitting or a transient problem.
  86. The former is something that can be limited, for the logical address,
  87. and the latter is ``only'' a transient problem.
  88.  
  89. Miscellaneous
  90.  
  91. ACTION: (Crocker) The spec needs to better detail the behavior of the
  92. _exit_ border routers (the last IPAE hop before the destination host.)
  93. More protocol mechanics.
  94.  
  95. ACTION: (Crocker) Spec should give an example of address handling, as
  96. IPAE datagram moves through the Internet.
  97.  
  98. ICMP
  99.  
  100. Sigh.
  101.  
  102. IPAE intends to permit permanent support for unmodified routers, within
  103. a commonwealth.  This means that routers will be generating current
  104. (old- style) ICMP message, which means ICMP messages without the full
  105. (IPAE, global) addresses of the originating host whose action triggered
  106. the ICMP datagram.  The exit border router (last hop before the router
  107. generating the ICMP) has the task of turning the ICMP into an IPAE
  108. datagram.
  109.  
  110. But it can't do that if it does not have the full global address of the
  111. originating host.
  112.  
  113. Only three options seem available:
  114.  
  115.  
  116.   1. Seek to have routers upgraded to generate larger ICMP datagrams, so
  117.  
  118.                                    2
  119.  
  120.  
  121.  
  122.  
  123.  
  124.      that they will include the IPAE header from the originating host.
  125.  
  126.   2. Have the Border router throw away ICMPs that it can't convert
  127.  
  128.   3. Have the Border router perform some sort of record-keeping of IPAE
  129.      datagrams, so that it can match the returned 64-bits with a full
  130.      IPAE global address.
  131.  
  132.  
  133. The Group discussed these options.  After appropriate (and large)
  134. amounts of illness-feeling, it was agreed that no other options seem to
  135. exist and all of the listed options were terrible.  Options 1 and 2 seem
  136. like the most constructive and practical, with option 3 unlikely.
  137.  
  138. ACTION: (Champlin) Survey existing router behavior, to determine the
  139. size of ICMP datagrams they actually generate, to determine if the
  140. theoretical problem is real.
  141.  
  142. ACTION: (Crocker) Verify Host Requirements statements about ICMP size.
  143.  
  144. ACTION: (Crocker) Add relevant text to Spec (not Transition doc) about
  145. this issue, including reasonable options.
  146.  
  147.  
  148.  
  149.                                    3
  150.